Software applications and application suites have become increasingly complex, constituting millions of individual functions available to users (e.g., a large company with hundreds of different job tasks). Further, software applications must be adaptable to customer demands. While software used to be released in versions, modern software is typically updated several times before a new “version” is established. A software enhancement package strategy may simplify the way customers manage and deploy new software functionality. Customers may selectively implement these software functions (e.g., as included in the enhancement package) and activate the software upon business demand. As a result, customers can isolate the impact of software updates from introducing/rolling out new functionality and bring new functionality online faster through shortened testing cycles.
The enhancement package model may deliver innovations through the enhancement packages approximately every year. Customers would no longer have to plan for major releases every five years. They could now choose to selectively implement the business functions or technical improvements that add the value that matters most to their business. Software developers may use enhancement packages to quickly and easily deliver business and industry-specific functionality, enterprise services, and other functions that help improve and simplify the use of existing software packages, through user interface and other end-to-end process improvements. This rapid, nonintrusive deployment of selected improvements may allow all customers to use the offered innovations according to the added value they bring to them and according to their own timetable.
Enhancement packages may be cumulative from a functional perspective, e.g., current enhancement packages may contain the entire content of earlier packages. So each enhancement package may be based on the previous one. Given the cumulative nature of the enhancement packages, function growth may be exponential, e.g., each added function may create newly added functions in future packages, while each may create new functions in even further future packages, and so on. Each function may not necessarily add future functions, but each function may potentially add new functions. For example, function changes may be required when legal requirements change, industry practice changes, business models change, market forces change, etc. Applicants have thus identified a need for various tools designed to facilitate the consolidation of these functions to minimize maintenance demands of the overall system. Example embodiments of the present invention may relate to an engine for facilitating the consolidation of individual functions.
As noted above, a software enhancement package may include a set of enhanced functionality that may be integrated into an existing software suite. Each enhancement package may contain new versions of existing software components and/or completely new functions. Within the enhancement packages customers may choose which software components should be updated in their systems depending on the new/extended functionality they want to use.
In enhancement package contexts, it may be the case that new functionality must be explicitly switched on to become active/visible in the system. A core unit of functionality within the system, and as described herein, may be referred to as a business function. The business function may also be the core unit within an enhancement package that can be activated/switched on. Activating a business function may trigger switches, which may then influence the execution of the code enhancements. These switches may ensure that customers only see and make use of the new functionality if they have activated them. The activation process may also start a job (e.g., a batch-job or cron-job, etc.) in the example system that automatically performs all changes in that example system.
Offering customers the choice of which software components are to be installed to a system and the choice to decide which and when a business function gets activated may increase the internal complexity of the software. Development teams may need to implement each change to most of the development objects in a switchable way. That is, it may not be possible to just change an object, but the developers may have to think about the consequence of any change. Developers may have to implement changes in a way that causes no effects in a customer's system so long as the switches of business functions are not activated. In addition, the number of the business functions may increase with every enhancement package, which may generate, e.g., after several enhancement packages, a huge number of business functions. This huge number of business functions may increase the risk of interferences between business functions, which may increase the complexity to be handled by the development teams. In this context, to maintain a high level of software quality, a decrease of development efficiency may be unavoidable. Sometime in the future, e.g., after enough enhancement packages, a level of complexity may be reached which decreases the development efficiency to an extent that cost-effective developments are no longer possible and/or countermeasures become indispensible.